關於Ray Project 的部分，其實很多人都不知道為什麼要需要用到Ray，對於Machine Learning 來說，除了資料跟 Model 架構的重要性之外，還有很大的挑戰就是計算資源跟計算速度，因為即使再好的演算法，如果沒有分散或者修改架構的話，其實會有計算資源的限制會影響計算的產出。
因此就與已過往的 Machine Learning 專案其實沒什麼兩樣，大多數的技術瓶頸在計算資源的問題，而資源的問題就變成要等以資源的大廠來先做 foundation model 然後在後面去做計算加速優化，但是這種技術常常都是要等別人先做才行，因此在Machine Learning 領域中，早晚都會碰到 computing resource insufficient 的狀況。
所以分散的部分就變成不得不面對的議題，而 Ray Project 也是基於分散的架構並且基於k8s 分散式的架構所產生出來的 Platform。
在現在的技術的演變下，由其實後面的kubernetes 系統架構，Ray 也藉由這個 Framework 的概念產生自己的 Raylet ，這邊再詳細的說明一下，因為有 Raylet 的出現，所以 Ray Head 就可以調派等待計算資源的 pods 去其他的 Node 上面使用資源，換句話說是 Processor 到不同的 node 上面，只要是屬於 Ray node 的部分，都可以調配使用（當然要注意 Torelation and Affinity)
這邊說明一下，Ray 的但是確實是因為 Machine Learning 的需求而誕生，因次對於ML lifecycle 度不份都有對應的項目下方幾項常見的東西
另外除了 Ray 可以提供什麼項目之外，首先要先搞懂 Ray 除了這些之外，最主要的是他來幫助 Scale up ，接著我把以上的情境在細說一下不同狀況的scale up 的情境
Head Pod 其實很簡單，就是負責接收 ray task 的窗口，只要有任何 @ray.remote 的 annotation 出現就會先把這些 Task Request 丟到 Head pod 上面，然後 Head pod 在分散到不同的 Ray Node 上面去執行。
另外一點就是關於 Ray Dashboard 的部分，主要還是在 Head Pod 上面才會看到 DashBoard ，另外還有負責開啟被指定爲 Head 的功能 --ray-client-server-port ，簡單來講，就是要設定這個 port 在 python script 上面才能把 job or task 送到head pod 上面，然後接下來在 Head Pod 上面所用到的計算資源， Head Pod 會送到 Worker Pod 的，所以就講到下一個
Worker Pod 其實很簡單，就是 Ray Cluster 食物鏈最低的角色，負責消化 Head Pod 丟過來的Ray Task 不過要特別注意的是 Package 跟 Path 的部分有沒有設定好，可能會造成找不到檔案的狀況，所謂沒設定好是 即便你分散了，但是檔案沒分散一樣找不到檔案 ，所以千望別想省事就跳過設定。
覺得設定很麻煩，如果是這樣的話，建議就不要使用 distribution pods，就乖乖的在擔心吃共同一台主機的資源就好
看影片追技術